i think this check is too restrictive and breaks my FastAPI application that uses SQLAlchemy and asyncpg. maybe it's better to track the loop ids instead of comparing the objects.

here's a stack trace:
https://gist.github.com/palash-taneja/5e5cf3947d95bfe886479caf8bcd8d27

@palash-taneja,

I did some research, and I have an alternate explanation: Your application likely has more than one event loop.

The code in the connector here correctly compares event loops. There is no possibility that the same asyncio event loop can be represented by two distinct loop objects.

Here's the evidence from your stack trace that your app has more than one event loop:

The first loop is runs the FastAPI router and the Cloud SQL Connector. This is the current loop when your application logs this message: "cloud_sql.py:116] [CLOUD_SQL] connect_async called from loop 5503254560, Connector was created in loop 550325456".

Then, the code calls the SQLAlchemy code session.execute(). SQLAlchemy session calls await greenlet_spawn at sqlalchemy/ext/asyncio/session.py:449. This likely switches the execution from the FastAPI event loop to a different one, probably the loop that was active when the SQLAlchemy library was initialized. I would look into how the SQLAlchemy library is initialized and make sure that its event loop matches the one in the connector. I hope you figure this out.

@hessjcg where are you seeing that in the log I sent? I think there's a mistake/some clipping of the text because the log says

"cloud_sql.py:116] [CLOUD_SQL] connect_async called from loop 5503254560, Connector was created in loop 5503254560"

not "cloud_sql.py:116] [CLOUD_SQL] connect_async called from loop 5503254560, Connector was created in loop 550325456".